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I. INTRODUCTION 


iiemialLnecOnuntoueLom Of Unis thesis is the design and 
analysis of an access control mechanism for the Multi- 
Backend Database System (MDBS). The design outlines of the 
access control mechanism have been suggested in [Ref.2]. In 
this thesis. the detailed design and analysis are given. To 


this end, we first present the general concepts of computer 


security. We then present the role of database security. 


pee 6COMPMIER SECURITY 


"Computer security deals with the managerial procedures 
and technological safeguards applied to computer hardware, 
software, and data to assure against accidental Oe 
deliberate unauthorized access to and dissemination of 
computer system data" [Ref.1]. The importance of computer 
security can best be appreciated if the computer is used to 
Store and process the information about military secrecy or 
proprietary industrial items. 

Computer security can be considered in four basic 


Bayers: physical security, hardware security, software 


security and database security. Physical security deals 
With the protection of computer against physical accesses. 
Physical access can be convurol led with managerial, 


MehuMteation. and.» authentication procedures. Hardware, 


software and database security are necessary only Saag 
physical access to the computer is accomplished. Hardware 
security deals with the protection of the user's data and 
program from other users by way of hardware protection 
mechanisms such as memory protection. software security 
deals with the protection of the user's data and program by 
way of software protection mechanisms. The basic mechanisms 
for software security are surveillance, threat monitoring 
and access control. Surveillance is to keep track of the 
user and the associated resources which are requested by the 
user. Access control deals with the user access 
authorization for resources’ during the program executitenm 
These resources can be programs, files, etc. Logically,the 
Operating system handles the access control with an access 
control matrix indexed by user-ids and resource-ids where 
each entry of the matrix consists of authorizations Momee. 
user to access the corresponding resource. 

Database security 1S concerned with the protection of 
databases stored in the computer. If data of a database 
must be kept confidential, then the database must be 
protected against unauthorized accesses. When ae large 
amount of confidential data must be processed and protected, 
the issues of database security become very important. 

Since our main subject 1s to provide am access Contre 
mechanism for a database system, we will elaborate the 


issues of database security in the following section. Other 
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Security issles “wallenot be the subject for discussion in 


Gis thesis. 


B. DATABASE SECURITY 

The principal problem for database security can be 
defined as determining who can access which data and what 
are the operations allowed on the data. This may be thought 
of as the same as the basic resource-access control problem 
which has been presented above. In eSsence, the problem is 
handled with the similar techniques, but, here, the argument 
is the comprehension of the semantics of the data rather 
than the basic resource-ids. For example, the basic question 
BOGeaccess COont@uol 1s to decide ‘'who' can perform ‘what' 
apewatvtlonseson 'Woicht datawein wkne database. First two 
questions can be argued for both the resource-access control 
and the database acceSs control, but to specify ‘which' 
portion of the the database is to be authorized for’ the 
users may be more involved with the data model and semantics 
of the data. 

Database management systems treat data differently than 
traditional data processing systems. Traditional data 
processing systems store data as a collection of values but 
database management systems store data as a collection of 
attribute-value pairs and relationships among the pairs. The 


attributes allow us to view the types or characteristics of 


corresponding values. The relationships allow us to relate 
one type of values to another type of values. 

In the database system under discussion (MDBS), we will 
consider database security for databases which are organized 
as attribute-value pairs. iiaes gives us uniform 
representation of information and we can keep track of some 


semantic relationships among data. 


C. ACCESS DECISION PROBLEMS@O@R DATABASE seein ir 

Access decision may be based on the following factors. 
Access deécysiom (One valuce sens itiwe i aeoemetenton depends on 
the current value ‘of data and the user's authorized value 
imi ts. Access decision on state-sensitive informagamam 
depends on the dynamic state of the database management 
System. For example, the user can open a file only if it is 
not in an unlocked state. There is pattern-sensitive 
information, such that, the user may be allowed to sort a 
file but he may not be allowed to read the content of the 
file. History-sensitive information must be proteeueg 
against a series of operations which may allow some 


inferences about unauthorized information. For example, if 


ranks and salaries of persons in the database are 
coincident, then the user can read the rank of a person and 
infer the salary. Event-sensitive information must be 


protected from the user during the unauthorized period. For 
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example, tellers can only access the system during the 
working hours. 

The access control mechanism for a database management 
System should protect all types of information presented 
above. However, Since protections of some of these types are 
difficult to implement, most systems do not implement for 


ele the by pes. 


Oreernechos CONTROL PRECISION 
After an access decision, the database management system 


must perform physical access to the database in order to 


fetch authorized and requested data. |The database 
management system should access only authorized and 
requested data. This is necessary for performance = and 
security reasons. A system which fetches only authorized 


and requested data is called a system with absolute 
peecilsion. Absolute precision must be the ultimate goal of 
database management system designers. 

Database management systems without absolute precision 
eause = the = pass-through problem, Since they fetch some 
unnecessary data in order to access the authorized and 
requested data. If the data which have been passed through 
have more stringent security feature then there may be a 
Security breach. The system should have either absolute 


precision or solve the bad aspect of the pass-through 


problem. 


In the next two subsections, some basic approaches for 
the pass-through problem will be deseribed: Detailed 
information can be found in [Ref.1]. 

i. Compamtmentaltazacien 

The data with identical protection requirements” are 
grouped and stored together. These groups) with uniform 
Security requirements are called Security Wavomsn security 
atoms become the unit for access. If we do not need all 
records in a security atom then we will have access 
imprecision. However, we will not have the pass-through 
problem, Since none of the unnecesSary records in the 
Sint atom ALL the higher level protection requirements 
than the authorized ones. 

a.) MUnaEevel Secure les, 

It may be desirable to classify the data in the 
database by hierarchical layers. The user may have access 
authorization up to a certain security level. This Siouaa 
can be combined with the security atom concepU. .eiaag 
security atom may belong to a classification level. So, the 
combination of security atoms with the same security 


classification can be used to create these layers. 


E. ACCESS CONTROL SYSTEM DESIGN METHODOLOGY FOR DATABASE 
SBS ETN RS) 


We have seen that database security deals with the 


Sem aie eS amo fama Before designing the access control 
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Svceeme the sdestener must study and analyze the system's 
data model. Since, most of the time, the data abstractions 
are very large and complex, this analysis must be very 
orderly and in only necessary detail. The designer has to 
look for a Standpoint to start. It can be an uniform data 
Mieee tor SeCuUrltywatemsconcept, etc. 

There is only one interface between the user and_ the 
database system, the request. The access control system must 
recognize requests and it must have a mechanism to start the 
access decision with information available in request. 

In the next chapter, we will give an overview of MDBS in 
terms of data abstraction, data meat ion language and 


basic request execution process in order to understand the 


system and utilize the system facilities in the access 
G@entrel mechanism. In the third chapter, we will describe 
mye basic design issues of MDBS acceSs control System and 
the access control information requirements.In the following 


chapters, we will elaborate the the basic steps of the 


eecess control system. 


II. AN OVERVIEW OF THE MULTI-BACKEND DATABASE SYSTEM (MDBS) 


—_—_———_—_——_ 
et 


In this chapter, we will introduce the general structure 
of the multi-backend database system (MDBS). MDBS has been 
designed in ([Ref.2] and [Ref.3], and the implementation of 
the system has been presented in [Ref.4], [Ref.5] and 
[Ref.6]. The information in this chapter has been extracted 


from Ref fy and thet sou. 


A.A TOP-{LEV Bi TEW (OR Spas 

One minicomputer functions as_ the controller, with 
multiple minicomputers and their disks configured in a 
parallel manner to serve as backends [Ref.2, Ref.4]. The 
database is distributed on secondary storage across all of 


the backends. User access is accomplished through a host 


computer communicating with the controller. The MDBS 
Structure can be classified as a centralized system, 
although the hardware is distributed. 

As shown in Figure 2.1, the controller and the backends 
are connected by a broadcast bus. When a transaction is 
received from the host computer, the controller broadcasts 
the transaction to all the backends at the same time. Each 
backend has a number of dedicated disk drives. Since the 
data is distributed across the backends, a transaction can 


be executed by all backends in parallel. Each backend 
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maintains a queue of transactions. When one transaction has 
been executed, the backend can begin execution on another 


Cransaction from its queue. 


fees SOR—}LEVEL VIEW OF THE MDBS DATA MODEL 

The data model chosen for the system is the attribute- 
based data model [Ref.2]. In MDBS the database consists of 
files of records. Each record is a collection of keywords, 
optionally followed by a record body. A keyword is made of 
an attribute-value pair such as <SALARY,$12,000> where 
$12,000 is the value of the attribute SALARY. A record body 
is a string of -characters not used by MDBS for’ search 


purposes. An example of a record without a record body is 


Shown below. 
PC meee rn eEMobey ce faciMmmonbE NAME YSsmath> ~~ <CITY,Columbus>, 
<SALARY,$12,000>, <SERVICE,10> ) 


The first attribute-value pair in all records of a file 
are the same. In particular, the attribute is FILE and the 
value is the file name. For example, the above record is 


from the Employee file. 
1. Keyword Predicates 
a GyVucimmp me ducdve.son Simply predicate, 13 of the 
form (attribute, relational operator, value). A relational 
Geemciommeamece one of the set { =, !=, >, >=, <, =< }. A 


Keyword K is said to satisfy a predicate P if the attribute 
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one or more 
disk c=lwee 





one Or ~ore 
Essk Ceivec 


Figure 2.1 The MDBS Hardware Organization 
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SITs ident icarero tne attribute In P and the relation 
Specified by the relational operator of P holds between the 
Value of K and the value in P. For example, the keyword 


<SALARY,15000> satisfies the predicate (SALARY > 10000). 


Ever Comlbypes of (Descriptors 
A descriptor can be one of three types: Type-A, 
Type-B and Type-C. A Type-A descriptor is a conjunction of 
a less-than-or-equal-to predicate and ae greater-than-or- 
equal-to predicate, such that the same attribute appears in 


both predicates. An example of a type-A descriptor is as 


foLlows: 


oer ere OCC mand (SALARY =< 10,000)). 


ferme simply, this 1S Written as (2,000 =< SALARY =< 10,000). 

A Type-B descriptor is an equality predicate. An 
example of a type-B descriptor would be (POSITION = 
Manager). 

MevpeeGmoeseChMpeOmmCOnSLSts Of ~only an attribute 
name, Known as the type-C attribute. Let us assume that 
there are n different keywords K1, Ke, ..., Kn, in the 
records of a database with a type-C attribute. Then, this 
type-C descriptor is really equivalent we n type-B 
Pocus Ecar 2.5 On, where Bi is the equality 
Pecati@avemsatistied by Ki. In fact, tnis type-C descriptor 
will cause n different type-B descriptors to be formed. From 


now on, we Shall refer to the type-B descriptors formed from 
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a type-C descriptor as UCype-C sub-desciminvocs. On 
instance, consider that DEPT 1S Specified asa Sty peee 
attribute for a file of employee records. Furthermore, let 
all employees in the file belong to either the Toy 
department or the Sales department. Then, two type-C sub- 


descriptors for DEPT will be formed aseiommea-- 
(DEPT = Toy) and (DEPT = Sales) 


3. The Relationship of Keywords and Descr uouem: 
A keyword is said to be derived or derivable from a 


descriptor if vone of the followine holds: 


(1) The attribute of the keyword is specified in a type-A 
descriptor and the value is within the range of the 


descrip. 


(2) The attribute and value of the keyword match those 


Specified in a type-B descriptor. 


(3) The attribute of the keyword is specified in a type-C 


deserilptor . 


4. (he luster Fonte taten 
For performance reasons, records are logically 
grouped into clusters based on the attribute values and 
attribute value ranges in the records. As described above, 
these values and value ranges are called descriptors. For 


example, one cluster might contain records for those 


ail 


employed in Columbus, making at least $20,001 but not more 
than $25,000 and with at least 11 but not more than 15 years 
emses vies. Thus records of this cluster are grouped by the 


following three descriptors: 
wor Columbus) ,($20 ,001=<SALARY=<$25 ,000) ,(11=<SERVICE=<15) 


These descriptors are said to define the cluster which 
contains records of employees in Columbus making between 
$21,000 and $22,000 per year and with 12 to 13 years 
experience would require the retrieval of records in the 
cluster just described. Other requests, SucCiewas vo Sfind 
records of employees in Columbus means between $21,000 and 
$28,000 and with 12 to 13 years experience, might require 
additional retrieval of records from other clusters than the 
one identified above. 

In MDBS, processing is done a cluster at atime. [In 
Saaers tO allow efficient processing of requests, records in 
a cluster are spread across all the backends. Thus~ each 
backend needs to search only its portion of the cluster. 
Given a user request, there must be a way, of course, first 
to determine which clusters to search and then to determine 
the location of records in a given cluster. To perform this 
task, MDBS utilizes available descriptor information. For 


example, given the previous request for finding employees 


where 
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(CITY=Columbus)and( $21, U0G=< SADA Gare eee 
and(12=<SERVICE=<13) 


MDBS first determines that two clusters must be searched, 
These are the clusters identified by the two setsof 


HesCcr torors: 


i (CITY =Cotumbu's), ($20.00 1=<SALARY=<toere oem 
(11=<SERVICE=s<15)} 


{(CITY= Columbus), (Ges. 00 1=<SALARY=<$30, BOO ws 
Chee eeuer <15)} 


After the clusters are identified, MDBS must then determine 
the disk addresses of the clusters at each backend. Finally 
MDBS will cause each backend to retrieve from its disks’ the 
records so addressed. 

Descriptor search determines the descriptors (igaae 
correspond to the request. In our example, there are four 


descriptors corresponding to the request; namely, 


CCITY=Columbus yy (s20 5000 = < Silt mu=rcene baseline 


($25 ,001=<SALARY=<$30 (O00) Pai Ginl= oaks Ghar ee 
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In order to save space and to save processing time each 


tecemepiver 1S ldencvii ted by a descriptor id. For example, 


$e ee = oe = wo a oo oe ee ee ee $oe eee eee - - - = - - - + + 
Descriptor | Descripeor Id | 
ee $oee ee o- = ------ =e + 
M@EcETY = Golumbus)) NS 
peer en mem m ww ow on oe ee ee ee $e eee ee we oe ee + 
meee O00 | =< SAE ARY =@ $25,000) Dales | 
$oe en om ow oo oe oe $oee—e—--- = -------- + 
Bees 25 700 | =ameNhLARY =< $30,000 ) D126 
+ eee ee ne ow oe oe ee ee $oe eee ee = === === + 
weelie=<  SERVLGE =<..15 ) D250 
$e ee er ee enn ow oo oo ow ee ee ee ee $e ee me ee oe ee = - = + 


Thus the output of the descriptor search phase is the 


Boolean expression of descriptor ids 
DiS and S@piies=ore@ 126) and D250 Ci) 


corresponding to 


($20 ,001=<SALARY=<$25K) 
mellY=Col) and or SCM ll=<omhwl Gk=< Io) 
Ceo OOM econbARY=<$ 30K) 


which identifies two clusters. The next phase, cluster 


search must take the Boolean expression in (1) and actually 
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determine the corresponding clusters. As with descriptors, 
clusters are also identified by ids, known as cluster ids, 


for example 


pee eee en ee eo oe ee $e eee eee ee ee ee = + 
Descriptor Ids Cluster Id 
$e eee eee oe ee ee poe ee ee ee eo oe ee ee + 
| DIS. 3piZz5eyub2ee Gly 
poe ee eee ee ee $e enn e = - - - = + 
' D15, D126, D250 | C20 | 
peewee nnn new eee ee fee ewe ee ee ee ee + 


The final two phases are address generation (to find 
the disk addresses, e.g., A3546 and A3547, corresponding to 
each cluster id, e.g., C17) and record selectionuians 
retrieve the actual records so addressed). 

Descriptor Search, §cluster ms seanes and address 
generation together form the major portion of directory 
management. 

Because all directory management is based on the 
concept of clusters, it is also logical to-@design an aceese 


control capability based on clusters. Thus cluSter Seancumem 


augmented by a cluster access control mechanism. 


Be, 


C. THE DATA MANIPULATION LANGUAGE 

The data manipulation language for MDBS is a non- 
procedural language which supports four different types of 
requests - retrieve, insert, delete and update. The syntax 
of these various requests and examples of them are presented 


below. 


ie Retrieve Requests 


A retrieve request 
RETRIEVE Query Target-List [BY Attribute] [WITH Pointer] 


Sonustsuseot five parts. The first partuais the type of the 
request i.e. RETRIEVE. The second part 1S a query which 
identifies the portion of the database to be retrieved. A 


aueGy = is ally ~ arbitrary Boolean expression of predicates. 


An example of a query 1S: 


((DEPT=Toy)and(SALARY<10000)) or 
((DEPT=Book) and (SALARY>50000) ) 


mies terget-list is a list of elements. Paciimmec bemecigiz "i's 
either an attribute, e.g., SALARY, or an aggregate operator 
to be performed on an attribute, e.g., AVG(SALARY). MDBS 
Supports five aggregate operators - AVG, SUM, COUNT, MAX, 
MIN. The values of an attribute in the target-list are 
retrieved from all records identified by the query. If no 


aggregate operator is specified on the attribute in the 
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target-list, its values in all the records identified by the 
query are returned directly to the user or user program jae: 
an aggregate operator is specified on the attribute in the 
target-list, some computation 1s to be performed on aliaeae 
attribute values in the records identified by the query and 
a Single aggregate value is returned to the user or user 
program. The fourth part of the request, referred to asman- 
BY-clause, is optional as designated by the square brackets 
around it. The use of the By-clause is explained by means of 
an example. Assume that employee records are to be divided 
into groups on the basis of the departments for the purpose 
Of ear cunarine the average salary for all the employees in a 
department. This may be achieved by using a retrieve request 
with the specific target-list, (AVG(SALARY)), and the 
specific BY-clause, BY DEPT. Finally, the fitth parv sone 
request, which is an optional WITH-clause, specifies whevmen 
pointers to the retrieved records must be returned to the 
user or user program for later use in an update request. 


Some examples of retrieve requests are presented below. 


Example-1 
Retrieve the names and salaries of all employees making 


more than $1000/month. 


RETRIEVE (FILE=Employee) and (SALARY>5000) (NAME,SALARY) 


2a 


Example-2 


List the average salary of all departments. 


Povey (ml b=pmplovees = (AVGCSALARY)) BY DEPT 


waeeensert Requests 


An insert request 
PSE Ry skRecorma 


Specifies a record to be inserted into the database. An 


example of an insert request is: 


INSERT (<FILE,Employee>,<SALARY,5000>,<DEPT,Toy>) 


Beeoe eve Requests 


A delete request is of the form: 
DELETE Query 


Wwnere the Query specifies the particular records to be 


deleted from the database. An example of a DELETE request 


ls: 
Dee temenaAMe=omitch) or CSALARY>50000) 


4. Update Requests 


An update request is of the form: 
UPDATE Query Modifier 


where the Query specifies the particular records to be 
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updated from the database and the Modifier specifies the 
kinds of modification that need to be done on records’ that 
Satisfy the query. In an update request, if a single 
attribute value is to be changed, then the attribute is 
termed the attribute being modified. The modifier in an 
update request specifies the new value to be taken by the 
attribute being modified. The new value to be taken by the 
attribute being modified is specified as a function f of the 
Old value of either the same attribute or some other 
attribute (say, attribute-1). More specifically, the 


modifier may be one of the following five types: 


Type=-0 >: <attribute=constant> 
Type-I = <attribuve-ouaure? pewe) 
Type-II : <attribute=f(attribute-1)> 


Type-III : <attribute=f(attribute-1) of Query> 


Type-IV : <attribute-=f(attribute-1) of Pointer> 


D. THE MDBS HARDWARE AND SOFTWARE ORGANIZATION 

MDBS is implemented in several permanent processes. The 
process structure within the controller and each backend is 
Shown) Laer igo eae see 

In the following two sections, we describe the functions 


performed in the controller and the backends, respectively. 


2S 


I 
| 


+rwewwrewewnrewwewewrewrewrerwenw ewww ewww @ ww www wn wn w@w@ ww www ww ww ww ww ew ew wm + 


CONT ROLLER 


~-oeerw ewe ee ee@e2 @ @e@ = + 


Preparation 
+ mew m wn ew wee e+ 


Request 


Post 


~-erwrewrewre2e2e2 e2ee2e2a2 + 


t 
J 
! 
J 


$e ee eee eee + 
Ins eee nino 
Generation 

+e ewww eee nee e+ 


+orwrwrwrnw ew eZ ee eww www wwwww ew @M Mew ew @ www wwe ew ww ew ew ww eww www ww ew wee oo + 


+ 
i 
11> 
a) 
1c 
' ® 
( 
i Sar ©) 
Mok 
Op 
i = 
!' oOo 
oo 
f 

+ 


-~orwr@ ew wee ewe we wwe @ @ ow ww ww ww ww wwe @ & ow ow ww ww ww ow @ ww ow ew ww ow ow ow @ oo = + 


peewee e we @= eee ~+ 


+-<orweweeeew @@e@ ow @ ao + 


—-oeweew ee eee @ @ @ + 


LH 
>a 
i oY 
Of 
ov 
© 0 
oO 
SS 
‘4 
AQ = 

Let) 

, 

LT | 

v) 
ae wie) 
.. 
Oo O 
Ome 
oO & 
om aA. 


-e@e @e @ @ @ @ @ @ @ @ + 


~-oeweeererereee ao a + 


=e ee ee se 


A BACKEND 


Figure 2.2 - The Process Structure in the Controller and 


the Backends. 
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1. Functions omepmemocurme hues 

The MDBS controller consists of three categories of 
func yvtons. request preparation, insert inf ofmaipaen 
generation and post processing. The request preparation 
functions are those which must be performed before a request 
or a transaction can be broadcasted to the backends. For 
example, each request must be parsed and checked for syntax 
errors before it can be broadcasted to the backends. The 
insert information generation functions are those which@ieae 
be performed during the processing of an insert request to 
furnish additional information required by the backends. Olg 
example, a backend should be selected for storing the record 
being inserted into the secondary storage of the backend. 
The post processing functions are those which muStRaEe 
performed after replies are returned from the backends, but 
before the results of a request or a transaction are 
forwarded to the host machine. For example, the results for 
a request returned by each backend should be collected. 
After receiving the results from each backend, the response 
to the request can be sent to the host machine. 

We note that there are no concurrency control 
functions in the Weentrol her. Since user requests”) are 
carried out by the backends, there is no need Lou 
concurrency control in the controller. Sihe controller mae 


Only associate sequence numbers with the user requests. 


Su 


Pe eeuUnict Mons eo! sodea backend 
denim ae Kehna nerlEo CONSiStS Of three categories of 
mode hLons : directory management, record processing and 


Sencurrency control. The directory management function 


performs descr] pions search, Cuisit er search, address 
generation and directory table maintenance. The record 
mmocess ing Luge elon performs record Storage, record 


retrieval, record selection and attribute value extraction 
of the retrieved records. For example, these functions 
Store records into the secondary storage, retrieve records 
from the secondary storage and select the records that 
satisfy a query from a set of records. The concurrency 
control function performs operations which ensure that the 
concurrent and interleaved execution of user requests will 
keep the database consistent. For example, these functions 
schedule a user request for execution based on the set of 
clusters needed by the request. Since, in this thesis, we 
deal with database security, handled in the backends, we 
will next describe the functions of the backends in more 


detail. 


a. The Directory Management Function 
Directory management has four phases: Descriptor 
Search, SUS cel Search, Access Control and Address 
Generation. The input to directory management is either the 


record part of an insert request or the query part of a 


se 


retrieve, delete, or update request. [ne three non-1neege 
request types, namely, retrieve, delete and update, requie. 
the same directory management processing. However, the 
insert request type requires a different directens 
Management processing. Thus we will describe directory 
management in terms of two categories: non-inserts and 
inserts. 

Directory management has four directory tables: 
The descriptor-to-descriptor-id table (DDIT), the attribute 
table (AT), the cluster-definition table (CDT) and_ the 
cluster-Id-to-next-backend table (CINBT) These tables are an 
integrated part of the directory nian agentes Logically, 
they are defined as follows: All the descriptors defined by 
the database creator are stored in the descriptcrm=eto-s 
descripuor—-tdagecavle (DDLIDe There is a descriptor id 
associated with each descriptor. There is an entry in the 
attribute table (AT) for every directory attribute. A 
pointer to the DDIT is stored with each directory attribute. 
The pointer points to the first descriptor whose attribute 
is identical to the corresponding directory attribuves A 
sample AT and DDIT are depicted in Figure 2.3. By showing 
these two tables together, we can easily depict the pointers 
of AT. The cluster-definition table has an entry fen eyems 
cluster. Each entry consists of the cluster number, the set 
of descriptor ids whose descriptors define the cluster, and 


addresses of the records in the cluster (Figure 2.4). The 
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Figure 2.3 A Sample Attribute Table (AT) 


Descriptor-to-Descriptor-Id Table 
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and 


(DDIT) 


See ee -eanwonaweosa=a= 
i Cluster | Desc-Id Set | Address (2am 
+—-22—-------- $e ee ee ee ee ee $oe eee eee eee + 
: C1 Losey Dad f A1,A2 : 
+22 e-------- $oe eee eee ee ee ee $e eee eee eee + 
| 2 | Co pepe ei) A3 | 
+2222 $e eee ee ee eee ee ee +e eee ee eee eee - 


(*) Secondary storage addresses for the records 


in the cluster 


Figure 2.4 A Sample Cluster-Definition Table (CDT) 


oS 


cluster-id-to-next-backend table (CINBT) is used as a basis 


of record insertion to the backends. Metts TLOOmvat Ene 


four phases of the directory management. 


(1) The Descriptor Search. In this phase, 
directory management determines the descriptor ids of the 
descriptors that satisfy the predicates (keywords) in a 
query (record). Pee “COM PeScripeor o¢€arcn comes from 
Request Preparation in the controller. As described in 
detail in [Ref.5], if there are N backends processing a 
query (record) with xX predicates (keywords), then each 
backend performs. descriptor search- on X/N predicates 
(keywords) and broadcasts the descriptor ids to the other 
mackends. 

(2) The €luster Search. In this phase, 
directory management determines either the cluster id of the 
cluster to which a record belongs (for an insert request) or 
the cluster ids of the clusters whose records may satisfy a 
query (for a non-insert request). Input to Cluster Search 
are the descriptor ids found by Descriptor Search in all the 
backends. For insert requests, Cluster Search passes the 
Sepyster id, if any, to Insert Information Generation in the 
Poaurelver., FOr tion—insert requests, tne cluster ids are 


passed to Address Generation. 
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(3) The Address Generation. “In this” pigisee 
directory management determines either the secondary storage 
address for storing a record when processing an insert 
request or the addresses of all the records in a set of 
clusters when processing a non-insert request. For iseme 
requests, Insert Information Generation in the controller 
determines which backend is to insert the record. When a 
backend is selected, Address Generation in that backend 
determines the secondary storage address Pons record 
insertion. That address and the formatted request are then 
passed to Physical Data Operation. 

| For mnon-insert requests, Cluster Search 
passes the cluster ids to Address Generation. Address 
Generation finds the addresses of the records in these 
clusters and passes the addreses and the formatted request 
to Physical Data Operation. 
db. The Record Processing Function 

This function perform operations Such as @meeoma 
selection and field extraction of the retrieved records. 
The names of these operations are: Physical Data Operation 
and Aggregate Operation. 

(1) The Physical Data Operation. Input to this 
Operation comes from Address Generation. The input is a set 
of secondary storage addresses and the request. Physical 
Data Operation performs different actions depending on the 


type of the request. For an insert request, Physical Data 


aiff 


Operation Stores the record being inserted into the 
secondary storage. 

HOumwa slOWU=iNSeru  kequest i.e. , = delete, 
retrieve or update, Physical Data Operation fetches the 
records from the secondary storage and selects the _ records 
that satisfy the query in the request. It then performs the 
intended operation on the basis of the type of the non- 
insert request. Fu@ue delete requests, Physical Data 
Operation marks the selected records for deletion. 

For retrieve requests, Physical Data 
Operation extracts the values from the selected records. If 
an aggregation is to be applied to the request, then 
Physical data Operation passes the values to Aggregate 
Operation phase of Record Processing. 

bon update requests, Physical Data 
Operation updates the selected records and returns to the 
secondary storage those updated records that have not 
changed cluster. If one or more records change cluster, 
Physical Data Operation marks the old records for deletion 
and sends the records that have changed cluster to Request 
Preparation in the controller. Request Preparation initiates 
the actions required for the insertion of these records into 


their new clusters. 
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(2) The Aggregate Operation. This operation 


performs the partial aggregate operations in retrieve 
requests. Input to Aggregate Operation comes from  Physimean 
Data Operation in the form of aeset of values and the 
aggregate operators to be applied. Aggregate Operation 
applies the aggregate operations on the set of values and 
passes the results to Post Processing in the controller. 

In chapter I, we introduced the access 
control systems in general. In chapter II, we gave an 
overview of the structure and the attribute-based data model 
of MDBS. In the next’ chapter, we will describe the access 


Gontrolemechanism ot MDBSe 


By 


Pel. wees CONTROL MECHANISM OF MDBS 


AS? === SR SSAA: |< AS 


We have seen that MDBS has four major phases. for 
maacevory Management: descriptor search, cluster search, 
feeeooecOMUmOl andmaddness generation. in descriptor search, 
MDBS determines the descriptor-id groups which identify the 
clusters requested by the user. In cluster search, MDBS 
determines the cluster-ids corresponding to the descriptor- 
id groups found at descriptor search. The access’ control 
phase eliminates the unauthorized cluster-ids. fen l Ly, 
Piuiress generation determines sesad ae storage Pudice= ses 
for the authorized clusters. In this chapter, we describe 


the access control phase in more detail. 


Pulse heer os CONTROL PRINCIPLES OF MDBS 

The access control mechanism [Ref.2], has been designed 
to utilize the parallel execution facilities of the 
backends. Let us see the basic principles of MDBS'sS' access 
control mechanism. 


Pe cceoomCONUnOL MUsSeeutilize the Advantages of the 


MDBS Architecture 

The basic idea of the MDBS architecture is to have a 
multiple backend system which performance most of the 
database management functions in the backends. Because of 


this architectural principle, the access control mechanism 


4Q 


is added to the function of the backends. Thus, we must 
Store the security-related information in the backends. Each 
backend only needs to store the subset of tables, which are 
pertinent to data stored in that backend. As a result, if 
the response time and the throughput of the backend system 
will be improved by parallel backend processing, then the 
access control function will also be improved accordingly. 
2. Access Control System snould not Decrease Ett teueme 
An access control mechanism amy bring additional 
overhead to asystem. It might be thought that additional 
access control checks on the records would slow down the 
request execution. However, We do not agree with this 
observation. If we have a mechanism to distinguish the 
authorized records from the unauthorized ones before record 
processing, then we need not fetch the unauthorized records. 
Consequently, we do not require secondary storage accesses 
for unnecessary, unauthorized records. In this way, we can 
improve the efficiency of the system for some requests. In 
addition, this mechanism provides absolute precision = and 
avoids the pass-through problem. 


3. Access Control System should not Provide only Staiae 


i ee eee eee 


pie CUIRIIDY MPO Plc Neem ons Dynamic Databases 


The database creator should have an ability to 
Specify the protection policy for each user at database 
Creation time. In addition, the database creator should also 


have the ability to specify the protection policy for new 
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users. Siucemecdmecdatabase Will not. be static due ee 
insertion, deletion and update of records, we want to have 
an access control mechanism to create new security 
specifications which fit the database creator's security 
DOoLlcy. 
4, hecessmmoonetolesmomld brovide Uniform Protection 
oC cCOmmmecunecl] ON Smmehes OAaMNe “Ohanacteristics 
We want to protect records with the same 
characteristics in the same way. Records with similar 
access control requirements should be stored together and 
isolated from other’ records with different access control 
requirements. Recall that clusters Be the collections of 
meocords With uniform characteristics. We want to store 
Similar records together in acluster. We can extend the 
concept of clusters to handle security. If we have security 
Specifications on a cluster then we can protect all records 
iecnis Cluster in the same way. Such a grouping of records 
Meaemoeen Called 4 security atom in chapter I. Utilization 
of the security atom concept will solve the pass-through 
problem also. 
ay Access Control System should Provide 2 lle 
Granularity 
In request execution with access control, MDBS 
sould also be restrict an operation on particular records 
in a cluster. For example, the access control system should 


prevent the update operations, if a record in a cluster has 
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a salary which is greater or equal to $2000. This feature 
brings access control to the field level (i.e., the level of 
attibute-value pairs) from the cluster or record level. With 
the field level access control, the mechanism provides a 
finer granularity of security. 

In MDBS, values of an attribute may be divided into 


different ranges. Each such attribute-range pair is called 


a descriptor. If we use descriptors ron security 
specifications, then we can protect the domain of the 
attribute values of the database. °~ Since clusters” are 


defined by sets of mutually exclusive descriptors on each 
attribute, we can also protect the clusters by employing 
their defining descriptors. Descriptors are created at the 
database creation time. Thus, the security specifications 
can also be created at the database time. If we want to 
have finer granularity on a particular attribute for access 
control, we can create descriptors with smaller attribute- 


value ranges. 


B. IHE ACCESS CONTROL REOUD EE iat SeiOeen bine 

MDBS should have an access control mechanism which 
protects value-dependent and pattern-sSensitive information. 
History=-sensitive and event-sensitive information is not 
considered as subject of the MDBS access control systems 
State-sensitive information is dealt with concurrency 


control mechanism. 
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Value-dependent access control protects data on the 
DasiS Of the relationship of the attribute value of the data 
and the user of the data. It is not enough to have 
protection on the value of a descriptor as the finest 
granularity of security. For example, the database creator 
may want to allow managers to retrieve the salary of 
employees in their respective departments. If we authorize 
the managers to retrieve the salary of employees, then the 
managers will have authorization to retrieve the salary of 
all employees whether or not they are in the managers' 
department. Thus, the access control must be dependent = on 
specific attribute value in order to provide value-dependent 
Security. 

Another requirement for MDBS access control system is to 
provide security TONG Statistics of the database by 
controlling the execution of requests which utilize the 


aggregate functions such aS average, maximum and minimum. 


See dit ACCESS CONTROL STEPS 

The access control checks described above occur at two 
Gis JOint times. The access control checks which are 
performed before any record retrieval are considered as 
Wee=processing while those which are performed after the 
GecOnwd retrieval are considered as post-processing. As has 
been stated in the second access control principle, pre- 


processing is one of the goals of the access control system. 
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In the next section, we discuss pre- and post-processing in 
more detail. 
1. Presprocessing 

Access control checks made prior to the retrievalieon 
records from the secondary storage prevent the access 
control mechanism from having to deal with unauthorized 
Records” Thus, access control precision is increasecdma. 
achieve this goal, we have to utilize information about the 
records available in the directory management, namely, the 
clusters information. Thus, we should perform some access 
control checks before the record processing phase and even 
before the address generation phase. 

In the preprocessing, the access-control checks’ are 
related to descriptors and elusters. We can utilize the 
descriptor and cluster information to perform pre-processing 
by having some security specifications specified by the 
database creator on the descriptors. 

2. Post-processing 

We recall that the records in a database consist of 
attribute-value pairs. Some of these attributes are chosen 
as directory attributes. Descriptors are then defined on 
these attributes in order to build clusters. The other 
attributes are non-directory attributes which are not’ used 
for defining clusters. The database creator may also want to 
Specify some security specifications on these attributes. 


In addition, an attribute may become more important because 
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of the dynamic nature of the database. The database creator 
may want to specify some security specifications on this 
attribute but may not want to redesign the database by 
making the attribute into a directory attribute. 

The non-directory attribute values of the records 
are not reflected in their directories. Consequently, the 
only way to determine them is to examine the attribute 
values of every retrieved record. This process can be 
performed after the record retrieval as a post-processing 
Operation. 

Allowing security specifications on the non- 
Pector yi attributes degrades a reer of the access 
control. If the database has no security specifications 9 on 
the non-directory attributes, then the access control system 
can achieve absolute precision. Consequently, the database 
emeavor must consider this situation. I[f certain attribute 
values should be protected, then their attributes should be 
defined as directory attributes. Nevertheless, we still want 
to provide a mechanism for post-checking in order to give 
flexibility to the database creator for later use of non- 
directory attributes for access control of the database. The 
MDBS post-processing mechanism would not affect absolute 
precision severely, since there is no reason to use non- 
directory attributes for security specifications at the 
database creation time. ites is built “in for ‘allowing 


flexibility in use by the database creator. 
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Dy: THE ~PREPROCESS ENGaene ers CONTROL INFORMATION AS 
SPEGIFIED BY RREw DA TABASHRCREATGOR 

In this section, we describe the preprocessing access 
control information which is specified by the database 
cretor at the database creation time. We also describe how 
this information is storeamin MDES. 

In order to decide on the authorization for a request, 
we need the information concerning who can perform what 
Operations on which data in the database. The database 
creator can specify the first two types of information 
easily. For example, for specifying 'who', _the- database 
creator can utilize user-ids which can be provided by MDBS. 
For specifying 'what', the database creator can select some 
of the access operations from the MDBS data manipulation 
language. Specifying 'which' portion of the database iS a 
more elaborate exercise requiring a more detailed knowledge 
of the data model. In the rest of the section, we will show 
to specify a 'portion' of the database in order to give some 
access rights on it. 

We know that a cluster is the basic unit of access in 
MDBS. As was argued in [Ref.2], we also want to utilize the 
cluster as the basic unit for access conprom. Thus, we 
expect the database creator to make some security 
Specifications at the cluster level. However, the database 
creator 1s not directly awared of the cluster formation. 


The database creator only specifies directory attributes and 
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Seo JOlNveedescriptors on these attributes. MDBS then forms 
the clusters for the database creator. Consequently, we can 
expect the database creator to specify the security 
seeecitiecations in terms of descriptors. 


We must find a way to transform the access’ control 


descriptors Gabout ee the faeldsjm to Bthe sauthorized and 
unauthorized cluster-level (about the records) Ris 
tieansformation will be addressed again later in this 
chapter. Pics weseWilweedisScuss = the specification and 


sworage of access control descriptors. 
dine Access Comtrols Descriptors 
The database creator specifies field-level access 
Eomnols  Onmeevne descmiptors for each user. A field=level 


pee os control Specitication iS agbriple of the form: 
(Aggregate operator, Attribute, Disallowed access operation) 


The form of a field-level access control specification has 
been S ine bby changed because of some implementation 
purposes, but the basic semantics is the same as given in 
Mref.2). 

The attribute in the field-level access’ control 
specification may be a directory or a non-directory 
attribute. The dissallowed access operation is one of the 
set {No Retrieve, No Delete, No _Insert, No update}. The 
aggregate operator is one of the aggregate operators of the 


MDBS data manipulation language (e.g., Max, Avg, Sum etc.). 
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The aggregate operator may be omitted in the specification. 
The attribute is not neceSsary for a field-level access 
control when the disallowed access operation is No Insert or 
No Delete, since we insert and delete the whole réecomamma. 
only an attribute of the record. 

A security specification (ss) for a descriptor may 
be ‘all' or ‘null’ or a collection of field-level access 
control specifications. A ss ofe'all' indicates hava 
accesses are disallowed for the respective user. A ss of 
‘null’ indicates that no accesses are disallowed for the 
respective user. The ss on a desScriptorn D 1s the coliegieaas 
of field-level access control specifications for the 


descriptor D. It can be represented as follows: 


(CD) Si Apecps ir dissallowed access op>,<----> 
praraiarens €----> 


FOr example, we might have the following 


descriptor-ss for the descriptor ©. (Ocal aay) ces 


(D) { <--,Job,No Update>, <Avg,Salary,No Retrieve>, 
<--,Name,No Retrieve>, <--,--,No Deleted, 
<--,--,No Insert> } 


The meaning of this security Specification iS iia 


follows: if a record has a salary between zero and 100, then 


the user can not update the job attribute of the record. Nor 
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can the user retrieve the average value of salaries and Name 
of the employees of all the records whose salaries are in 
the range of zero and 100. In addition, the deletion and 
insertion of any record with salary between O and 100 is not 
authorized. 

We store all the descriptor-based security 
Speciiications for each user in a descriptor-to-security- 
specification table Coss il). This table and ines 
implementation are discussed in the next two subsections 

Be ilcmmee csc mor —nO—seCcuriby—-opecification ~~ Table 

(DSST) 

Pogicallve DSot can be incorporated reece: an 
meemented DDTT ‘by adding to DDIT one column per user. See 
Figure 3.1 below. Instead, we would like to store _ the 
descriptor-level access conrol information in a seperate 
descriptor-to-security-specification table as shown in 
Migure 3.2. 

There are several reasons to have a seperate table. 
First, the descriptor-based security specifications are 
database-creator-specified access control information = and 
are used to create cluster-level access control information. 
They are not used directly for request authorization. We 
have decided that MDBS would use cluSter-level access 
Sentrol “information for request ate Weir ez. bl Ora. Such 
cluster-level access control information is created once, at 


the database creation time. It is used whenever we need to 
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Gealewith that cluster. Ime descriptor-level access control 
information is then no longer used directly. 

The second reason for a seperate DSST is that these 
security specifications are of variable length whereas the 
DDIT entries are of fixed length. Consequently, it is more 
appropriate to separate variable length entries from fixed 
length length entries, if we do not use them at the same 
time in an operation. 

The third reason for a separate DSST is that each 
user may have a distinct ss on a descriptor. All these 
Seesuinet security Specifications must be stored. If the 
database has a large mee OF neeree ae nen the main function 
oes UDiIT which is ‘the mapping from descriptor to 
descriptor-id' will be very inefficient. 

3. The Secondary-Storage-Based DSST 

Each user in the database will have a column in DSST 
memecepicted in Figure 3.ce. If the database has a large 
number of users, then we may want to store the DSSTs in the 
secondary storage. Except as discussed in Chapter V, we use 
the DSST only at the database load time to create the 
cluster-based security specifications. Thws, it will be 
efficient to store the DSST in the backends' secondary 
storage. We can just fetch the particular user's DSST or 
part of the DSST when it is needed. 

Figure 3.3 shows a sample of the secondary-storage 


based DSST. Each database in MDBS will have aeeuser-index 
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The Secondary-Storage-Based DSST 


Figure 3.3 


oye: 


Cable in the backends' main memory. The user-index will have 
a pointer to the DSST entry for each user. 

In the DSST, we deal with the descriptor-ids rather 
than the descriptor boundary values. This’ gives us the 
opportunity to use a simple layered indexing technique with 
variable length security specification entries. 

#7 the Cluster—level, Access Control. Information 

After the database creator has defined the 
descriptors and the descritor-level access comtcol 
information, then the database loading mechanism can create 
the elusters and the cluster-level access control 
matormation. 

A cluster has been defined by a set of descriptors. 
The cluster-based security specifications are the union of 
the corresponding descriptor-based security specifications 
in the cluster. Consequently, the descriptor-based security 
Specifications and the cluster-based security specifications 
can be represented in the same way. If the cluster is 
defined by only one descriptor, then the cluster-based 
Security specification and the descriptor-based security 
specification will be the same. If the cluster is defined 
by more than one descriptor, then the union of the 
descriptor-based security specifications will be the 
cluster-based security specification. 

PerelsmullUstmaremmow tO ObCadan the cluster-level 


access control information from a set of descriptor-based 
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security specifications. Consider the database with four 
employee records depicted in Figure 3.4. The database 
creator first specifies some of the attributes as the 
directory attributes and then specifies some descriptors on 
the basis of these attributes. This information is stored in 
the DDIT (Figure 3.5). In this example, “the attrib 
Salary and Department, have been specified as the directory 
attributes. The attribute of the descriptors Dl and Daum 
Salary and descriptors D3 and D4 is Department. In addition, 
the database creator defines descriptor-level access control 
information on each descriptor for every user ~ 7ieame 
database. This information is stored in the DSST (Figure 
3.5). Now, the database creator has provided necessary 
information for the directory management and the access 
control mechanism. Using the entries and the information in 
the DDIT, MDBS can form clusters and this informatii@meee 
Stored in the CDT (Figure 3.7). 

With the descriptors corresponding to a cluster (in 
CDi and the descriptor-based security specifications 
corresponding to the descriptors (in DSST), we can determine 
those security specifications corresponding to the cluster 
and store them in the cluster-to-cluster-based-security- 
Specification table (CSST)(See Figure 3.8). For example in 
Figure 3.8, the cluster-1 is defined by the descriptors D1 
and D3. In Figure 3.6, the descriptor-based security 


Specifications on the descriptors D1 and D3 for the user-1 
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Figure 3.4 A Sample Database with four Employee Records. 
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for the Database of Figure 3.4. 
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are Omer x Consequently, the cluster-based security 
specification on the cluster-1 for user_1 will be "“Haneae 
User 2 has descriptor-baseq security specification. as 
'none' for descriptor Di and {<--,Name,No Update>} for 
descriptor D3. Consequently, the cluster-based security 
Speciiicavion on cluster-1 for user 2 will be {<-- 
,»Name,No Update>}. By repeating this process, for every 
cluster and every user in the database, the cluster-level 
access control information can be determined. 

Table (CSST) 

The cluster-level access control information is 
stored in an augmented CDT which is the CDT with an 
additional column not user-cluster-based security 
specifications. Each user has an augmented CDT. The 
augmented CDT is used in the cluster search, access control 
and address generation phases of directory management. 

In the cluster Search phase, the cluster-ids for 
those clusters whose records may satisfy a request are 
determined. In the access control phase, the cluster=ias 
whose records are not authorized for the user are determined 
and the unauthorized cluster-ids are eliminated. In _ the 
address generation phase, the secondary storage addresses of 
the authorized clusters are determined. 

In [Ref.6], the access control information has not 


been considered. The CDT. without access conten 
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information, has been implemented as two secondary-storage- 
based tables. ieee Cercle iS the  idescriptor=to- 
descriptor-id-bit-map table (DCBMT). The second table is the 
cluster-id-to-secondary-storage-address table CESS 
DCBMT is used for the cluster search phase and CSSAT is 
used for the address generation phase. We will store the 
m@eeess Control information of CDT in a third  secondary- 


storage-based table called the cluster-to-cluster-based- 


security-specification table (CSST). 
6. The Secondary-Storage-Based CSST 


Since each user needs only one CSST, we will need to 
store CSSTs in the secondary storage. We will store the 
user-index in the main memory of the backends and we will 
have one pointer for each user's CSST table(Figure 3.9). 

Cool UGPlizes es tme  cluster-ids for indexing. The 
user-CSST pointer leads to the cluster-index for that user. 
The cluster-index cells have upper and lower’ cluster-id 
value. We look for the cluster-index cells whose values 
cover the cluster-id in consideration. Each cluster-index 
has a pointer which leads us to the cluster-based-security- 
specification set. The cluster-level access Coneno. 
information is stored in the corresponding cluster-based- 
Ssecurity-specification set cells. Each entry in the set has 
Space for a certain number of field-level access controls. 
If there are two many field-level access controls, then some 


will be stored in an overflow block which can be found by 
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User index 
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The Secondary-Storage-Based CSST 


Figure 3.9 


Sl 


following a pointer from the cluster-based-security- 


specification set. 
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Ly) Wee Re PROCESS oe 


In this chapter, we will describe in more detail the 


preprocessing of the requests utilizing the access cGom@med 


information. NS Lee eune Orner phases Of; directory 
Management, the access control mechanism distinguishes 
between insert requests and non-insert requests 
(retrieve,update and delete). The difference between an 


insert request and a non-insert request is that the insert 
request deals with only one cluster, at a time while the 
non-insert request may deal with many clusters at the same 
time. In the following two sections, we will, in turn, 
describe the preprocessing for non-insert and in Seine 


requests 


A. PRE=PROCESSING FOR NON-INSERT REQUESTS 

Directory Management with access control has foun 
phases; descriptor search, cluster search, access CcoOmgmga 
and address generation. Directory management starts with 
descriptor search which finds the descriptor-id groups for 
the request. Then cluster search finds the cluster-ids for 
the corresponding descriptor-id groups. When all cluster-ids 
are obtained for the request, access control checks are made 


in order to produce 4 list of autem dee uuiniren = 1dlcr 


68 


Since access control for the non-insert requests’ works 
on clusters, we can utilize the cluster-level access control 
information for the request authorization. The request 
plem@orization 1S performed in Cwoestepse The first step is 
pumisuer Security specification search and the second step is 


cluster authorization decision. In the following two 


subsections, we will elaborate these two request 
authorization steps. 
ime cluUcuwer cecurity Siecificationmsearch 

Cluster security specification search for a non- 
insert request begins with a list of cluster-ids £LOrF 
clusters to be authorized. We will use the cluster-based 
security specifications, stored in the CSST (Figure 3.9), as 
the access control information. CSST has three layers of 
indexing; user-index, cluster-index and cluster security 
specification set (cs-set). The user-index may be stored in 
the main memory, while the rest of the table is stored in 
the secondary storage. An algorithm to search CSST is as 
follows. 

After the cluster search phase, for the cluster-ids 
found, the access control phase is started. First, the 
access control mechanism refers to the backend's main memory 
and finds the particular user-id in the user-index. The 
user-index shows us whether the user can access the database 
or. not, fice USChmmismenOt vauithorized to access the 


database, then the request is rejected. If the user is 
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authorized to access the database, then a pointer to the 
cluster-index is fetched from the user-index. THUS , ee 
first layer indexing (the user-index) allows us to check the 
user-access rights to the database. 

With the pointer found in the usSer=index, themaae: 
block of the cluster-index is fetched from the secondary 
storage. Each cluster-index block has cells whitch havew@one 
upper and one lower bound cluster-id, and one pointer. If a 
cluster-id is between the upper and lower bounds of a cell, 
then we say that the cell covers this cluster-id. The 
pointer in the cell leads us 1/0) the ecs-set which has ais 
clusters covered by the corresponding cell. For example, in 
Figure 3.9, the first cell of the cluster-index has _ lower 
bound as Cl and upper bound as Ck. Consequently, The 
cluster-ids between C1 and Ck are covered by this cell = and 
the pointer in this cell leads us to the corresponding cs- 
set block for these clusters. The above procedure is 
repeated for each cluster-id yielding a pointer to the cs- 
set for eacn of the corresponding e<lusters. 

It can be observed that the strategy to search CSST 
is to search it one layer at a time. For each block fetched, 
the corresponding operations are performed for all clusters. 
This strategy prevents redundant accesses to the CSST 
blocks. 

The next step is to search all the cs-sets. Recall 


that each cs-set block stores the access control information 
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for a certain number of clusters. Each cluster in the cs-set 
Mes Spaces for a part of the Security specification which is 
a certain number of field-level access controls. If a 
cluster has more field-level access controls, then they are 
stored in an overflow block which can be reached with a 
pomnver. 

The ecs=-set blocks are searched one at a time, 
starting with the ecs-set block for the cluster with the 
Smallest cluster-id. A cs=set block is searched for all 
clusters we are dealing with. After the processing of the 
Seeocto sare Completed for all clusters, additional field- 
level eee controls for clusters are fetched from overflow 
eesocksS Utilizing the pointer obtained in the cs-set. 

eee Cluster AULCMOnI zation Decision 

The cluster-based security specification for each 
cluster to be authorized has been provided from CSST in the 
cluster security specification search. Now, the access 
control mechanism should utilize the user request and the 
cluster-based security specifications in order to decide 
about the cluster authorization for the request. 

In [Ref.3], the relationships among the disallowed 
access operations in order to prevent compromising the 
access gontrol mechanism are described. These 
meoreatlomsmips, Called the access control implications, are 


as follows: 
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NomRetr il ever—— = ss NicwUipdace 


No Retrieve ---» Nompelete 
No Update ---> No Delete 
NomDieWe tie ---> No Update 


The determination of the security specificaticqneiiiaor 
each cluster to be authorized is the same for all types of 
non-insert requests. However, the processing On ties 
information for each type of request is, of course, 
different. This processing will be described in the next 
three subsections. 

a. The Authorization for Retrieve Requests — 


The syntax of a retrieve request is: 
RETRIEVE Query Target-List [BY Attribute] 


Where the Quer Veeism@eanly Sieainonseie cin, Boolean expression of 
predicates which identifies the portion of the database to 
be retrieved. The target-lisit@eis amiiist oO mmme ementice Each 
element is either an attribute, e.g., SALARY, or an 
aggregate operator to be performed on an attribute, e.g., 
AVG(SALARY). We support five aggregate operators - AVG, SUM, 
COUNT, MAX, MIN -—- in MDBS. Let us have an example using the 
database in Figure 3.4. The retrieve request could be as 


ROU LOwom 


RETRIEVE (File=Employee) and (Department=2) (Avg(Salary) ) 
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The meaning of the above request is to retrieve 
the average salary of the employees who are in department 2. 
Let us assume that directory management has_ performed 
descriptor search and cluster. search. Determining that 
clusters C2 and C4 may contain records’ satisfying the 
request. The access control mechanism performs the cluster 
security specification search for user-1 as described in the 
previous section and finds the security specifications from 


the CSST (see Figure 3.8) as follows: 
(C2) {<---,---,No Delete>} 


(C4) {<Avg,Salary,No Retrieve>,<---,---,No Delete>!] 

The request calls for retrieving the salaries of 
the records in cluster C2 and cluster C4. User-1 does not 
have any contradictory security specification for retrieval 
Srecbuster C2, sinee cluster C2 has a security specifacation 
Gameems Only restricts the deletion oof records. This check 
Operation is performed as_ follows. The access control 
mechanism compares the attribute sme) the security 
specification gs which is null, and the attribute in the 
target-list part of the request (i.e. salary). Since they do 
not match, it authorizes the cluster. In the case of cluster 
C4, the security specification has two field-level access 
controls. Let us consider the first field-level access 
control. The aggregate operator of both the field-level 


access control and the request match (i.e. average). In 
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addition, the attribute of both the field-leével “semee— 
control and the request match. Now, the access control 
mechanism checks the disallowed access operation. Since it 
is No Retrieve, the request 1S not authorized to retrieve 
the records of cluster C4. As a result only the cluster C2 
is authorized for this request and the user 1S warned as 
only authorized records have been retrieved. 

Let us now consider a slightly different request 


as follows: 
RETRIEVE (File=Employee) and (Department=2) (Salary) 


The query in the request is the same as in the previous 
example. However, the target-list calls for retrieving the 
Salaries of particular employees instead of the average 
Salary. Since the query is the same as in the previous 
example, clusters C2 and C4Y will again be the _ satisfying 
elusters. In the first field-level access control for 
cluster C4, we see that the retrieval of the average salary 
is not authorized. But here we want to retrieve only the 
individual salaries. Now, we will have an access’ control 
implication: if a request with an aggregate operator is not 
authorized, then the same request without aggregate operator 
Will also not be authorized. Thus, for example, if the 
retrieval of the average salary is not authorized, then the 
retrieval of the individual salaries is also not authorized. 


The inverse of this implication is not true. That is, ever 
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if we have restriction the retrieval of salaries, retrieval 
of the average salary can be authorized. We can state this 


as follows. 
<Avg,Salary,No Retrieved> ---> <---,Salary,No Retrieve> 
<---,Salary,No Retrieve> -/=-> <Avg,Salary,No Retrieve> 


We can add this rule to the access control implications as 
the fifth access control implication. We should recall that 
the aggregate operations are used only in retrieve requests. 
The fifth access control implication can be stated more 


formally as follows. 


<Agg-op,Attr-A,access op-8> ---> <Agg-op,Attr-A,access op-8> 


b. The Authorization for Delete Requests 


The syntax of a delete request is: 
DELETE Query 


where the query specifies the particular records which will 
be deleted from the database. Let us consider an example for 


a delete request from user-1. 
DELETE (File=Employee)and(Salary=1000) 


User-1 wants to delete those employee records 
which have salary as $1000. The query has only one predicate 


which is covered by the descriptor D1 (see Figure 3.5). 
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Consequently, cluster C1 (defined by descriptor D1 and D3) 
and cluster C2 (defined by deseriptor D1 and D4) ecotmmama 
records which may satisfy the request since they have 
records with salary less than or equal to $1500. 

The cluster security specification search of the 
CSST shown in Figure 3.8 finds the security specifications 
of clusters C1 and C2 for user-1 are as follows: 

(C1) NONE 


(C2) {<X---, ---, No Delete>} 


Cluster C1 does not have any security related restriction. 
Consequently, we can reach the records R1 and R2 (See CDT in 
Figure 3.7). We should recall that cluster C1 contains those 
records which have salary less than or equal to $1500; but, 
the request needs only those records with salary equal to 
$1000, in this case record Ri. 

According to the security specificatlonmeien 
cluster C2, the user is not authorized to delete a record in 
cluster C2. Consequently, the delete request for cluster C2 
is rejected. In addition, according to the access CGonmiaga 
implications, even if the dissallowed access operation were 
Now Rietimieve on No Update, then cluster C2 woulamiipe 
unauthorized. As a result, only the record #1 in clusteniiies 


Will be deleted. 
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ec. The Authorization for Update Requests 


The syntax of an update request is: 


UPDATE Query Modifier 


where the query specifies the records to be updated and the 
modifier specifies the update operation. Five basic modifier 
types have been specified in [ref.4] and briefly described 
in chapter 2. Each of the modifier types try to alter the 
value of one attribute. Since the security specifications 
Specify the disallowed access operation for the attributes, 
we can have an authorization decision immediately after we 
mead oll the attribute to be modified. 

Let us consider an example of an update by 


useree., 


UPDATE (File=Employee)and(Dept=2)and(Salary>1500) 


<Salary=Salary+50> 


User-2, with this request, wants to increase by 
$50 the salary of those employees who are in Department 2 
and have salary greater or equal to $1500. Cluster search 
determines the satisfying cluster as only cluster C2, which 
is defined by descriptors D2 and D4. Cluster C2 has_ the 
security specification with only one field-level access 


control for user-2 as: 


ie 


{<--,salary, No Update>} 


The access control mechanism compares the attribute in the 
each field-level access COmtirou Of the security 
specification (here Salary) and the attribute in the 
modifier (here again Salary). If they did not match, then 
the cluster would be authorized. Since they match, the 
access control mechanism looks at the dissallowed access 
operation. Since the dissallowed access operation is 
No Update, the cluster is not authorized. Here, we Navemuae 
one satisfying cluster for the query and this cluster is 
unauthorized. Thus, the request will be rejected. Daim 
dissallowed access operation were No Retrieve or No Deiieges 
then the request would also be rejected because of the 
access control implicationsmules:, 

In the previous sections, we have described the 
preprocessing for non-insert requests. In the following 
section, we will describe the preprocessing for insert 


me@ues to. 


B. PREPROCESSING FOR THE ENSER eRe ee 
The MDBS data manipulation language specifies the insert 


request as follows: 
INSERT <Request> 


where the Request is of the form {<Attribute,Value>, <-->, 


-, <-->}. AS stated previously an insert request differs 


fs 


from non-insert requests because it refers to ae_e single 
unique cluster. The actual processing of an insert request 
depends on whether or not this cluster already exists. In 
the following subsections, we will describe the 
MimcorocessSing Of an insert request in detail using the 


following example: 


INSERT {<File,Employee>,<Salary,1250>,<Dept,TOY>} 
wis ciocmmcauescs Lor an Existing Cluster 

In the case of an insert request, descriptor search 
may be performed by more than one backend, but the actual 
insertion will be done by only one backend. If the cluster 
already exists, i.e., already contains other records, shes 
the backend will also have the cluster-level access’ control 
information in its CSST. The access control process for the 
insert request with an existing cluster is performed only by 
the one backend which is to perform the actual insertion 
Operation. The access control mechanism in this’ backend 
handles this kind of insert request the same as a non-insert 
request with one cluster. 

At the end of the descriptor search, the satisfying 
descriptor-id group is determined. The cluster-id search 
Will determine the unique cluster-id from CDT for the 
descriptor-id group. The backend, chosen for the insertion, 
will perform the cluster security specification search on 


this cluster-id. This search is the same as the cluster 
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security specification search described for a non=amiseme 
request. Having been provided the security specification for 
the cluster and the user-id, the access control mechanism 
will check the authorization on the request. If the security 
specification does not have any disallowed access operation 
as No Insert, then the request will be aun Omeacan 

Let uS now consider the example insert request for 
the database in Figure 3.4. The user wants to insert an 
employee record for an employee, who will have salary of 
$1250 and who will be in department 1. In descriptor 
search, the satisfying descriptor on attribute Salaryaieee 
found as descriptor D1, since descriptor D1 covers  aimmuem 
the salaries which are less than or equal to $1500 (see 
Figure 3.5). The descriptor for the attribute department is 
found as descriptor D3. Thus, the descriptor=id groupmien 
this request is descriptors D1 and D3. In the cluster-id 
search, directory management searches the CDT (see Figure 
3.7) for the descriptor-id group and the cluster is found to 
be cluster C1. After this point, processing is the same as 
the access control phase of non=-insert requests ae 
security specification for cluster-1 will be searched from 
the CSST and the security specification will be examined for 
authorization of the request. 

2. Insert Requests into the Empty Cluster 
A second caSe occurs if all of the descriptors for 


the insert are already defined, but this insert is the first 


{2 


wie or one wciluster Getinea by Chis descriptor=-id group. In 
this case, no information about the cluSter can be found in 
the directory. Consequently, we can not find any cluster- 
based security specifications for this cluster. However, 
~eacemamenot the descriptors are the existing descriptors, 
we can find the descriptor-level access control information 
in DSST. Thus, we can derive the cluster-level access 
control information from the descriptor-level access control 
information as described in the algorithm in section [III-D- 
ae 

The descriptor-based security specifications for 
each descriptor are fetched (from DSST. The union of the 
descriptor-based security specifications is stored in CSST 
as the Cluster-based security specification for this 
@eeover. After this point, the authorization step for the 
request is performed as before. Thus, for example, if one of 
the disallowed access operations in the cluster-based 
Ziwnney specification is Nosinsert, then the request is 
rejected. 

The method described above has an efficiency 
problem. We derive the cluster-based security 
wcecimleauron, Store it in CSST and then perform the 
ainnorigatilonm decision. If the insertion is authorized, 
then the record is inserted. If it is not authorized, then 
the insertion is rejected. Tueeeears Case, the effort to 


update the CSST has been performed even though no insert 


76 


acinnial ly aeCiours: We should find a better solution to 
overcome this inefitrerency. 

We reject an insert request if the dissallowed 
access operation in a descriptor-based security 
specification is No Insert. During the DSST Search, wom 
check the dissallowed access operation for each descriptor. 
If we find a dissallowed access operation of No Insertesiamea 
descriptor-based security specification, then the request 
can be rejected immediately. In this case no update to the 
CSST will be performed. If none of the descriptor-based 
Security specifications has the disallowed access operation 
of No Insert, then thewpeques sls au Ghommccamaad the CSST 
can be updated accordingly. 

3. Insertekequests Sintoman new eemucic 

A third case arises if the request needs to create a 
new descriptor. In this case not only will the clustemeage: 
exist, but there will be no descriptor-level access control 
information for this new descriptor. Thus, of course, we 
can not derive the cluster-level access control information 
as was described in the last section. 

Insert requests with a new descriptor introduce two 
new problems. The first is ‘Who can create a new 
descriptor?' The second is ‘How can the descriptor-based 
SeCluimiey specification for the new descriptor be 
Sspecified?'. The first question must be answered Drior “£eé 


the actual request authorization. Consequently, the access 
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eontrol process for the insert request with a new descriptor 
can be divided into three phases; the new descriptor 
wecadnnen autherization, the aceess control information 
Specification for the new descriptor and the total request 
amiEnorization. 

In the initial access control design in [Ref.3], the 
problem created by a new descriptor has not been addressed. 
We will analyze this problem further in the following 


chapter. 
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V. INSERT REQUESTS WII THE NEW DESCRige oD: 


In chapter 4, we described the preprocessing for insert 
and non-insert requests utilizing the cluster-level and the 
descriptor-level access control information developed in 
chapter 3. At the end of chapter 4, we described an insert 
request with a new descriptor and observed that there was no 
access control information at the cluster-level or the 
descriptor-level for this kind of request. In this chapter, 
we will describe the access control information and the 
access control methods for insert requests with a new 
descriptor. Let us look first at what the reason is to have 


a new descriptor. 


A. THE REASON FOR THE NEWSDES GRICE Lon 

The database creator specifies the descriptors for Type 
A and Type B attributes as an upper limit and a lower limit 
on the attribute value. Thus, we never need to create a Type 
A or Type 8 descriptor, since the value of the predileage 
attribute will fall within the boundaries of the 
descriptors. However, if the attribute is of Type C, then 
each value ot the Type C attribute will result in a distinct 
descriptor. For example, if attribute Department Is of Sige. 
C, then Department TOY and Department SALES are the distinct 


descriptors. Since each value of the Type C attribute 


ie 


results in a Type C descriptor, there may be some values 
which are not defined as descriptors by the database 
creator. For example, if Department ADVERTISING has not 
been defined earlier but we want to create a new department 
as ADVERTISING then we create a new Type C descriptor on the 
Type C attribute department. We may even need to create more 


than one Type C descriptor for an insert request. 


Pree tae AUTHORIZATION REQUIREMENTS FOR A REQUEST WITH A NEW 

DiPSGR LP TOR 

In the directory management processing without access 
control, the new descriptors are created and broadcasted by 
@iemeoneroliéer. This process is done as follows. In the 
descriptor search phase, if the backend can not find the 
descriptor for a predicate, then it looks at the type of the 
predicate attribute. If the attribute is of Type C and the 
request is an insert request, then it sends a message to the 
controller to create a new Type C descriptor. The controller 
creates a new descriptor and broadcasts it to the all 
backends. The backends receive the new descriptor and store 
it into the proper tables. 

Directory management with access control requires us’ to 
add two more steps to the process described above. The first 
Step is 'the authorization step for the new descriptor' and 
the second irs "the descriptor-level access control 


seceliiecavilon tor the new descriptor'. What will be the 
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order for these steps? New descriptor creation 15 a ego ue 
process in terms of the number of messages among the 
backends and the controller. Thus, we will try to to avoid 
the unnecessary creation of a descriptor. Obviously, the 
new descriptor authorization checks will be performed before 
the new descriptor creation. Total request authorization 
also depends on the other descriptions. security 
specifications as well, we should refer to DSST to check the 


security specifications for all of the descriptors in the 


cluster. 
Another necessary operation is to specify some 
descriptor-based security specifications for the new 


descriptor. The new descriptor's security specification is 
specified and stored in DSST, and the cluster-based security 
specification is derived from all of the descripvenmes 
SGCCUrI UY sDeClTl Tearlons. 

Now, we Know what we should do for the insert request 
with a new descriptor. The order of the operations and the 
methods for the operations must still be determined. In the 
following sections, we will elaborate the steps of the 
process in order to see and assess the various choices. 
These steps are the new descriptor-creation authorization, 
the new descriptor creation operation, the descriptor-level 
access control specification for the new deScriptor) seme 


authorization decision for the old descriptors and the 
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Museen ey elaeceecsocweconlLGO. Information derivation for the 


new cluster. 


Pee lHE NEW DESCRIPTOR CREATION AUTHORIZATION 

Wwe Know that each value of a Type C attribute is 
considered Ove GemoiostmMech nl yoe uC sub=-descriptor. if 
department and job are specified as Type C attributes, then 
each values of one of these attributes is also the value of 
a distinct Type C sub-descriptor. The creation of a new 
department defines a new descriptor. Another example can be 
to add a new job to the system. The access control question 
for this Kind of operation can be stated more formally as 
‘who is the person allowed to create a new descriptor. on 
this attribute?'. This question can be answered by the 
database creator at the database creation time, since it 
depends on the basic organizational schema. 

moeMDBS, deletion and creation of an™®attribute is not 
allowed after the database is first created. Since the 
attributes are permanent, we can give some security 
Specifications on the attribute-level for the future 
descriptor-creation authorizations. These security 
Specifications will be on Type C attributes for each user in 
mae database. We Sto gemuOnemmUSen-descriptor—creation 
authorizations in a New-Descriptor-Authorization Table 
(NDAT). 


1. The New-Descriptor-Authorization Table (NDAT) 

We store the descriptor-creation authorizations for 
each user on the Type C attributes in this table (Figure 
5.1). The descriptor-creation authorization on each Type C 
attribute for user i is a boolean expression. In Figure 
5.1, we can see that creation of a new department is 


authorizedeiior user 2 Dlily nO tistege seme 


2. The Secondary Memory Based NDAT 


We may want to store NDAT in the secondary storage, 
Since the dimension of NDAT depends on the number of the 
users in the database which may be large. Figure 5.2 shows a 
NDAT oF BIE secondary-based implementation. | 

The entries of NDAT are the user-ids. Onlyaieeie 
authorized Type C attributes for the new descriptors are 
listed in NDAT. Thus, each user will have a variable length 
entry with the attribute-ids in it. We may not want to use 
well-structured indexed or B-Tree constructions for this 
table, since the number of the Type C attributes in the 
database is not large. In addition, most of the users will 
nave creation authorization only for a subSet of these 
attributes. In Figure 5.2, we can see that user 1 i@ag 
create some new descriptors on the attributes which are 
listed. However user n is not authorized to create any 


descriptors. 
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Figure 5.2 The Secondary-Memory-Based Implementation 


of New Descriptor Authorization Table (NDAT) 
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Creve wn DESCRIPTOR CREATION, TIME 

We know that the request authorization for the insert 
requests with the new descriptor depends on either the new 
descriptor-creation authorization or the access 
authorization for the old descriptors. The new descriptor- 
creation authorization can be performed before the creation. 
If we create a new descriptor and the request is denied 
meeause Of the old descriptors’ security specifications, 
then we will have an unused, unnecessary descriptor. 


Let us consider the following insert request for user 1: 
JOSS ab oie Laieye e000, (JOD; sALESMAN> ,<Depet, 10Y>} 


where both attribute Department and attribute Job are Type C 
attributes and the predicate values, TOY and SALESMAN, do 
Moree eCXlst as deseriptors. Thus, new Type C descriptors 
should be created, TOY for the attribute Department, and 
SALESMAN for the attribute Job, respectively. 

Assume there are three or more backends and descriptor 
search for predicate 1,2 and 3 will be performed by backend 
ime and 3, respectively. Taws; backend 1 performs 
descriptor search on the attribute Salary and finds the 
corresponding descriptor. On the other hand, backend 2 can 
not find descriptors for attribute Job with the value 
SALESMAN. Backend 2 looks at the type of the attribute Job 
Acme mndseous that it is a Type © attribute. Consequently, 


backend 2 wants to create a née: Job as SALESMAN. Now, 
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backend 2 has to check whether or not user 1 is authorized 
to create a new job. Backend 2 performs the new 
descriptor-creation-authorization checks for user “og 
attribute Job. This operation is performed as follows. The 
NDAT block for user 1 is fetched from the secondary Wego 
via the pointer provided in the user-index for user 1. We 
search the block to find the attribute Job. Since Job is in 
the block, we conclude that user 1 is authorized to create a 
new job. Thus, backend 2 requestsS a new descriptor, namely 
SALESMAN, from the“controlYer. The controller creates auiiien 
descriptor and broadcasts it to all backends. 

Similarly, backend 3 performs fe search on the 
attribute Department and finds out that no descriptor exists 
PO eo ve line performs the new descriptor-creation- 
authorization check on attribute Department for user 1. 
Since attribute Department is not indicated in the NDAT 
block for user 1, user 1 iS not authorized to createmammen 
department. The request must be totaly rejected. Now, we 
have created a descriptor, namely SALESMAN, but we could not 
insert the record. Thus, we have a descriptor for a name not 
in the database. In addition, we have wasted an effort for 
the new descriptor “creation whieh fo umecsu ly. The same 
problem would also arise with predicate 1. If the user does 
not have an access right for insertion of the records which 
have salary of $2000. Some possible strategies to avoid 


this problem are described in following sections. 
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1. Method-1 for new Descriptor Creation 

This method tries to create the new descriptor. as 
the last step. Each backend first tries to decide about the 
creation authorization for the new descriptor and the access 
Ge norization for the old descriptors. If everything is 
authorized, then the backend sends a status message to the 
other backends. After receiving the status messages from all 
the backends, we can conclude that the request is authorized 
and we can demand new descriptors. The controller creates 
the new descriptors and broadcasts them to the backends. 

e. Method-e for new Descriptor Creation 
The problem with method-1 is efficiency, since’ each 
backend has to wait for all statuS messages before 
requesting a new descriptor creation. Method-2 allows’ the 
backends to create a new descriptor whenever it is needed, 
and if the request is denied, then the new descriptors. are 
deleted. 

The new descriptor deletion operation is requested 
by the creator backend from the controller. The controller 
deletes the new descriptor and broadcasts a deletion message 
to the backends. 

iiiesemethod 1S also sinefficienct.. In the worst case, 
if there are N backends in the system, then we need N 
additional messages from the backends for deletion and one 
broadcast message from the controller. In addition, we will 


have some deletion overhead in the controller. 
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3. Method-3 for new Descriptor Creation 

Method=-3 also allows the backends to create a new 
descriptor whenever it is needed. The controller creates a 
new descriptor by assigning a descriptor-id and it does not 
keep track of the value of descriptors. Thus, if the 
backends do not store the new descriptors into DDIT and into 
other tables, then there 1S no way to reach them again. If 
the backend needs the same descriptor for a later request, 
then the controller will assign another descriptor-id for 
this descriptor regardless of its prior existence. The only 
problem for this method is an increase of the number of 


descriptor-ids because of some nonexistent descriptors. 


4. he Sequence of an Insert Request with the  Supenmien 


Method-1 is superior to others in terms of the 
uniform handling of the problem, the lack of side effects 
(e.g., the artificial descriptor-id increase seen in 
method-3) and relatively modest overhead. Let us elaborate 
method-1 and see the complete sequence for an insert 
request. 

Directory Management receives’ the request and 
performs AT search for each predicate assigned to that 
backend. If there are Type C attribute in the request, then 
they are locked, and descriptor search is performed for each 
predicate, as follows. For each predicate, the backend 


reads the DDIT, finds the attribute and the proper 
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Meise POLOrs Onuumies attribute. If the attribute type is Type 
eT avemeetieresmmssno descriptor for this attribute with this 
particular predicate value, then we need to create a new 
mepe, GCesdescriptor with this predicate value. The backend 
ions sau NDAT in order to check "creation authorization" for 
the user on this’ predicate attribute. If the user is 
authorized to create a new descriptor on this attribute, 
then the backend continues descriptor search for the next 
predicate. If the user is not authorized to create a new 
descriptor on this attribute, then we deny the whole 
mequesv. 

After descriptor search is done for all predicates, 
the backend broadcasts them and waits to get descriptor-ids 
from the other backends. With this broadcast message, the 
backend sends a flag indicating that a new descriptor is to 
be created. 

The processing for any type of insert request is the 
feemem Until this point. There may be two cases at this 
point. The first case is that no backend needs to create a 
mew descriptor, i.e., this iS an insert request with an 
existing or empty cluster. The second case is that one or 
more backends need to create a new descriptor. We have 
elaborated the first case in the chapter 3. Let uS consider 
the sequence of processing for the insert request with a new 


descriptor after this point. 
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The backends start "descriptor-level access control 
process" on the descriptors that they have broadcasted. 
There is no cluster for this request available to be 
inserted into and to be checked for cluster-level access 
control information. We have not yet created the new 
descriptor. We delay the creation until after the descriptor 
level access control process. 

Let us look at the descriptor-level access control 
process, which is the same as for an insert request with the 
empty cluster. There is only one descriptor-id group (for 
the request since insert requests have only one cluster. If 
we check user authorization for aon sesoripeer and each of 
the descriptors contains positive insert authorizations, 
then we can deduce that the request is authorized. This 
process is performed by all of the backends. After positive 
authorization decision is completed, the backends which need 
new descriptors request new descriptors from the controller. 
When the controller sends a new descriptor creation message, 
the backends start to store this new desriptor in the proper 
tables, and they create a new cluster and the cluster-level 


access Control informauren. 
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Me lde ACCESS CONTROL INFORMATION SPECIFIGATIONSFOR THE NEW 

Dio hae ORS 

We still have to find an answer for the question "Who 
can access to a cluster which is defined by this new 
descriptor"? For example, if the new descriptor is a new 
department, namely, TOY, then the question will be ‘who can 
read the salaries of the employees in this department’ and 
who can not?'. Can we decide about this specification in 
advance? Let us elaborate some choices for answers to this 


question. 


ele UsOCmmmnomeume NCOCeSs Conthol Specification for a 


new Descriptor 


This method requires the database creator to specify 
all security specifications at the database creation time. 
We have already decided that the new Type C-descriptor- 
creation authorizations for each uSer would be specified at 
the database creation time. Now, we have to ask ‘can we 
also specify the user access authorizations on this new 
descriptor at the database creation time?'. In some cases 
Ey may be possible. For example, the director of a 
department will have right to read 'new employee's’ salary'. 
This is very appropriate in terms of a static security 
BoOLicy. However, we may not be able to predict all 
necessary security specifications for new descriptors in 


advance. For example, suppose we want to create a new 
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department which is a totally new managerial decision. It is 
possible that it does not fit into the regular pole. 
Specified in advance. Thus, we will need some additional 
security Speciirveavions. Thus, the \soiuelon tem Gaus 
problem may be to specify clear and available security 
specifications at the database creation time and to use the 
database administrator/creator's security specificataen 
facilities to change or add new security specifications 


later. 


2. Method 2 for the Access Control Speciticationmiamu 


ee ee ee eee 


new DeSch lp von 


It is clear that we may not be able to specify all 
security specifications for some specifie descriptors at the 
database creation time. If we have the flexibility to 
specify some security specifications after descriptor 
creation time, then we will have an additional problem of 
dealing with an insecure gap between the descriptor creation 
time and new access control information specification time. 
We may not want to specify the new security specifications 
at the new descriptor creation time in the same insert 
request, since such a specification will be too slow for the 
insert requests. This gap must be covered by an additional 
security mechanism to prevent unauthorized accesses. One 
alternative is to ‘assume full restriction for all users' at 


the beginning and than EO insert some securiley 


o 5) 


specifications to authorize some users to access if such 
access is needed. In this way, the system will have no 
insecure gap and the system will be easy to handle in terms 
of the overhead. 

3. A Comparison of the methods 

Method 1 provides a more secure and opractical 
security mechanism. With method 1, the overhead will appear 
at the time of insertion the new security specifications. 
Initially, we will isolate all users from the newly created 
descriptor and therefore from the new cluster. Thus, all of 
the cluster-based security specifications will be "all 
accesses are disallowed" for all of the Mrserss We do not 
care about each descriptor's security specifications in the 
new cluster in order to derive the cluster-based security 
specification from the descriptor-level access control 
mrormation. 

If we want to authorize a user with an access) right 
on the new descriptor, then we have to go back and check the 
Security specifications for the other descriptors in the 
defining cluster. That is, we must determine if there are 
amyeaesecriptors with more strict security specifications. 
Mmemone “of the old security specifications is more strict 
than the new security specification, then we accept the old 
one and we warn the user. Let us consider the following 


example: 
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INSERT {<Salary,10000>,<Job,SALESMAN>,<Dept,TOY>} 


Let us assume that the security specifications in the 
augmented DSST fOlls user 1 on the descriptors intima 
satisfying cluster are as in Figure 5.3. Let the new 
cluster be defined by three descriptors where descriptor De 
is the new descriptor for SALESMAN. The default security 
specification for the new descriptor is ‘all accesses are 
disallowed for wisely Weve cluster-based security 
specification will be the union of the descriptor-based 
security specifications of the corresponding descriptemae 
Here, the security specification of descriptor De owerhelms 
the others and the olustenspaced security speci piieat tae oe 
the new cluster for user i will be ‘all accesseeiaa. 
disallowed'. 

If we want to authorize user_i to read  ~fese 
emloyees' salary who are SALESMAN, then we change descriptor 
De's security specification. The new security specification 
will have all possible accesses are disallowed except 
retrieval of the Salary attribute. After this descriptor- 
based security specification has been changed, we have to 
rederive the cluster-based security specification. For this 
process, we have to look at the DSST, the security 
Specifications for descriptors Da and DD; in order to ‘irae 
Sure that other descriptors in the cluster do not have any 


conflicting sec unmmeey specifications which would not 
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authorize user i to read SALESMEN's salary. In this exageme 
descriptor Da has the restriction for user 1, such eae 
user_i can not retrieve the SALESMAN's salary if the salary 
of the salesman is between 0 and 10009. Since the salary is 
in this range, the modified descriptor-level Se CURA 
specification will have no effect on the cluster-based 
Security Speecit ication. 1.e., descriptor Da's s@cuminm 
specification (salary,No Retrieve) is the most straiee 
restriction. Thus, the cluster-based security spéecifileavien 
Will be unchanged as ‘'ALL'. 

If descriptor Da did not have a restriction on the 
Satie wath: Qe sal mess then ee cua specification 
derivation would be different. We would have specified a 
field-level access control as <salary,No Update>, Sin@emme 
want user i to be able to retrieve the salaries of the 
employees but not to change them. 

We have elaborated the directory management 
information based postprocessing in chapter 3,4 and 5. [In 
the next chapter, we will elaborate postprocessing phase of 


the access control system. 


otf 


Werth eOolr wOGE So ITNG 


iMeemapver Eilemwes described how access “control was 
divided into preprocessing postprocessing, and we developed 
the database-creator-specified access control information 
for preprocessing access control. In chapter 4 and 5, we 
have elaborated the preprocessing access control. ie S 
chapter, we will develope the access control tools of 
postprocessing. In the rest of the chapter, we will use the 
term ‘postprocessing! for the postprocessing step of the 
access control whenever there is no confusing with the 


Belaeprocessing tunctlon of the controller. 


Meco CEh os CONTROLS IN POSTPROCESSING 

We described the MDBS access control system mostly as 
preprocessing. Recall that preprocessing is restricted to 
the directory attributes. Now, we also want to establish a 
protection mechanism on the non-directory attributes. In 
preprocessing, we have been able to restrict some operations 
on the non-directory attributes. For example, the descriptor 
containing the attribute value TOY has been specified on the 
directory attribute Department. In addition, the attribute 
Salary is a non-directory attribute. AsSuming that the 
descriptor-based security specification for TOY is: <-- 


Soler ye Omnetniever. Ine meaning Of the descriptor-based 


98 


security specification above is: the user can not retrieve 
the salaries of those employees who are in the department 
TOY. Thus, we protect a non-directory attribute (Salary) 
from an operation (retrieve) with regard to the value of a 
Gireetory attribute (department=TOY). The purpose of 
postprocessing is to establish protection on the direc ea 
or nonedirectory attribute with regard to tne valvemomea 
non-directory attribute. If the attribute department in the 
previous example were a non-directory attribute, then the 
access control would require postprocessing instead of 


preprocess ince. 


B... THE POSTRROCESS RG Eee 

We know that each backend in MDBS has three major 
functions: directory management, concurrency control and 
record processing. We also know that access COntren 
preprocessing is performed in directory management utilizing 
the directory management related information. 

Postprocessing deals with the values of the non- 
directory weavtribuves: There is no way to determine the 
physical location of the records with regard to their  non- 
directory attribute values. Thus, we can perform the 
postprocessing only after record retrievals by the record 
processing function of the backends. 

Record processing has two major functions: the physical 


data operations and the aggregate operations. A physical 
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data operation depends on the type of the request. For 
insert requests, the physical data operation stores the 
records into the secondary storage. For non-insert requests, 
the physical data operation first fetches the records from 
the secondary storage and filters the records which do not 
satisfy the query in the user request. It then performs the 
intended non-insert operation such as the deletion of 
record, update of an attribute value of the record or 
extraction of some attribute values of the record for a 
retrieve request. An aggregate operation performs’ the 
partial aggregate operation for the backend. 

In the physical data operation, 7Seeeem sentinel entails 


mm@emerOllwing: First, it wili check that the user has any 


security specifications specified on the non-directory 
attributes. If the user does not have any security 
miectileations On the —=mon—-directory attributes, then the 


access control will have no affect in record processing. Let 
uS assume that the user has some security specifications. on 
the non-directory attributes. During the physical data 
operation, the backend fetches the records one track at a 
time. Each record is checked to see whether it satisfies the 
query in the request or not. If the record does not satisfy 
the query, then Le is pemered=eameatter this step, 
postprocessing checks will be performed for each satisfying 
record. After postprocessing, the satisfying and authorized 


records are sent to the aggregate function of record 


100 


processing. In the following sections, we will describe the 


access control information and the steps in postprocessing. 


oe THE POSTPROGESS (NG Ae CPSs eco Wer INFORMATION AS 
SPECIFIED BY TED A Alstom co meceelbOn 

In this section, we will describe the database-creator- 
specified access control information for postprocessing. We 
will also describe how to store this information. The main 
idea of the access control information for postprocessing is 
the same as the access control information described in 
Chapter III for preprocessing. We, again, want to answer the 
following question: who can perform what operations on which 
part em the database. Specifying Ae eoisliaeye two items in the 
question will be the same as for preprocessing. This 
information is obtained from the user-ids and the access 
operations, respectively. Specifying '‘which' portion of the 
database depends on the security specifications on the non- 
directory attribute values given by the database creator. 

The database creator specifies attribute-level access 
controls on the non-directory attributes. An attribute- 
level access control specified on a non=-directory attrisamiae 


LS Of ene etonin: 
<Lower ,Upper ,Aggregate op,attribute,disallowed access op> 


where lower and upper are the domain limits on the 


attribute, the aggregate operator is one of the aggregate 
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Seeravrors, the abunrouLe 1S a2 directory or non-directory 
attribute and the dissallowed accessS operation is one of the 
set {No Retrieve, No Update, No Delete, No_Insert}. thie 
aggregate operator may be used only for the attribute-level 
access controls with disallowed access Operation as 
Meenetrieve. The attribute entry is only included when the 
essallowed access operation is No Retrieve or No Update. If 
the non-directory attribute which will be protected has 
Single value instead of value range, then the upper’ value 
will not be specified. 

The difference between the field-level access controls 
for preprocessing and_ the AERA ECOL anen access controls 
for postprocessing are as follows. The field-level access 
controls are built on the descriptors while the attribute- 
level access controls are built on the non-directory 
attributes. In addition, for the attribute-level access 
controls, the value boundary to be protected is specified 
with the upper and the lower bounds which indicate the value 
range on the non-directory attribute. The rest of the 
access controls are the same. 

PubcdGuimmouLe ssecuriiby Specificationymay be ‘all” or a 
collection of attribute-level access controls. An attribute 
Seeley especification of ‘all’ indicates that all accesses 
are disallowed for the respective user. The attribute 
a Cees peeciricallom, on an attribute is the collection of 


attribute-level access controls for the attribute. It can be 
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represented as follows: 


(Attribute) {<lower,upper,Agg op,Attr,disallowed access op>, 


en ee SoS 


For example, we might have the attribute Se@ Cums 
specification on the non-directory attribute Salary for the 


various ranges of the Salary as 


(Salary) {<1000,2000,--,Job,No Update>, 
£<1000,5000 ,--,--,No Delete>, . 


<4000,5000,--,--,No Insert>} 


The meaning of this attribute security Specification is as 
follows: the user can not update the Job attribute of a 
record, if the record has a salary between $1000 and $2000. 
Nor can the user delete a record if the record has a salary 
between $1000 and $5000. In addition, the insertion of a 
record with Salary between $4000 and $5000 is not 
authorized. 

We store the access control information LOR the 
postprocessing phase into the two layers of tables, tne 
non-directory-attribute table (NAT) and the  attribute- 
security-specification table (ASST). These tables and Cheam 


implementations are discussed in the next two subsections. 
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e Non-Directory-Attribute Table (NAT) 

There is one NAT (see Figure 6.1), if the user has 
some restrictions on the non-directory attributes. In the 
NAT, we store only those non-directory attributes which have 
an attribute Security specifications specified on them. The 
user=-index in the backends' main memory has a pointer’ for 
the NAT for each user. If the user does not have any 
restrictions with regard to the nonedirectory attribute 
values, then this pointer will be null. The NAT corresponds 
hee the attribute tCadle in directory management. The 
secondary storage-based NAT implementation is also the same 
as the attribute table cRef.6]. Thus it will aoe be 
elaborated here. Each attribute in the NAT has a pointer Je 
mae. corresponding ASST for the attribute. Themes ol. 1s 
described in the next subsection. 

2. The Attribute-Security-Specification Table (ASST) 

We store the attribute security specifications for a 
particular mnon-directory attribute in an ASST (Figure 6.2). 
Thus, each none-directory attribute in the NAT has) an ASST. 
The relationship between the NAT and the ASST is shown in 


Figure 6.3. We store the ASST in the secondary storage. 


tree DHE POSTPROCESSING OPERATION 
The output of directory management is the secondary 
memory addresses of those records which are authorized by 


preprocessing. Those records are fetched and field-level 
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Figure 6.1 A Non-Directory-Attribute Table (NAT) 
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Figure 6.2 An Attribute-Security-Specification 
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values are examined by the record processing function. In 
the physical data operation part of record processingggae 
records are fetched from the secondary storage a track at a 
time. Each record in the track is examined to see that it 
satisfies the query in the request. For satisiying ye@oameiem 
the operations necessary or the request type 
(insert,delete,update, retrieve) are performed. Since the 
postprocessing deals with the field-level values of the 
records, we can perform postprocessing in the physical data 
Operation part On the record processing fune vane 
Consequently, we will perform the postprocessing operation 
for the records eat Tenmaae the ance 

Before record processing is started, we will look at the 
user-index. If the pointer to the NAT is null in the user- 
index, then record DrOcessiung will gene have any 
postprocessing checks. If the user does have a pointer to 
the NAT, then we search the NAT. The NAT stores the non- 
directory attributes which have security specifications on 
them and a pointer to the ASST for the corresponding 
attributes. We fetch all the ASSTs with the pointers 
provided from NAT. All the attribute security specifications 
in the ASSTs are brought into the backend's main memory, 
Since we will use all this access control information for 
each record. Now, we are ready to perform the record 
processing with postprocessing capability. For each record, 


if it satisfies the query in the request, then we will 


ines 


Periorm the postprocessing cnecksS on it. This operation will 


be described in the following section. 


Pur oP OsTPROCESSEING AUTHORIZATION PROCESS 

The authorization process in postprocessing is the same 
as the authorization process in preprocessing (Chapter IV). 
The only difference is: we deal with records me 
postprocesing whereas we deal with clusters LG 
preprocessing. This process 1s done as follows. For. each 
attribute security specification obtained from ASSTs, the 
record's corresponding non-directory attribute-value is 
pocanedk Teh the attribute value is not between SHOMOD er 
and the lower values of the attribute security 
Specification, then we conclude that the record can be 
authorized for this attribute security specification. The 
same operation is performed for the next attribute security 
seecett1cation. If the attribute-valuegis between the upper 
and the lower values of the attribute security 
specification, then we perform exactly the same 
authorization process of preprocessing for each request type 


(see Section IV-A-2). 
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Vil.” seeNcrUS TON 


In this thesis, we have described the design and 
analysis of an access control mechanism for the multi- 
backend database system (MDBS). The design of this access 
control mechanism is based on two major objectives. The 
first objective is to introduce an access control Capapimmiaa, 
to MDBS without changing the existing parts of the system. 
The second objective is to have an access control mechanism 
Without adding excessive overhead to the system. To 
aowstien Tae Pnese Site ouaeee the access control mechanism is 
incorparated into the directory management. Thus, access 
control is performed before any record is retrieved. 

In addition, the capability to protect information yams 
does not have directory has been provided. This capabilities 
can be exercised by the database creator. The user is 
allowed to create a new Type C descriptor with an insert 
request, if the user is authorized to create a new 
deseaiup torn on the corresponding attribute. The access 
control information for the new descriptor is specified by 
the database creator. Furthermore, the database creator is 
provided with the capability to modify the access’ control 
inf ormatlone 

As an access control principle, if the request seme 


partially authorized, then the partial result 18S givenmge 
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the user with a warning. For example, let us assume that the 
user wants to retrieve the names of those employees whose 
Salaries are higher than $2000. However, the user is only 
authorized to learn the names of those whose salaries are up 
to $5000. In this case, MDBS will give the user the names of 
those whose salaries are between $2000 and $5090 and will 
warn the user that there are other names which are not 
Aamemorized for the user. 

The access control information for each user is_ stored 
in the descriptor-to-descriptor-based-security-specification 
table Cbs Sie the cluster-to-cluster-based-security- 
Meciirication table (CSST) and the non-=directory-attribute 
table (NAT). Entries in these tables are reached by 
following pointers in the user-index. For simplicity, we 
stored the user-index in the backends’ main memory. For a 
database with a large number of users, it might not be 
feasable to store the user-index in the backends! main 
memories. The user-index can then be stored in the backends' 
maeoncary storages and the user's portion can be brought 
into the main memories at the log-on time. 

Finally, the access control mechanism of MDBS has been 
designed to handle the value-dependent and pattern sensitive 
information (see Chapter I). It also provides’ protection 
for statistical data. Furthermore, it overcomes the pass- 
through problem, since records in a cluster are protected in 


the same way (i.e., only the authorized records are 
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accessed. The unauthorized records are never passed-through 
the access control mechanism, nor are they accessed. See 


Chapt tal 119= 
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